Networking devices are frequently tested using a network tester application that creates test patterns to flood a network device with packets. A typical test setup includes a tester application running on a workstation that has network ports connected to the network device. A typical packet contains digital data organized with a pre-determined pattern, and includes header information as well as a payload. The tester application manages the outgoing and incoming test patterns, commonly including Ethernet frames or internet protocol (IP) datagrams, monitoring the performance of the network device under various test conditions. The tester application can then create reports and statistics for the network device, enabling manufacturers to understand and improve upon the performance of the network device. Exemplary tester applications are commercially available from Spirent Corporation and IXIA Corporation.
Prior to manufacture, hardware designers frequently employ simulators and/or emulators to verify the functional behavior of the electronic devices and systems fabricated in accordance with their designs. One type of verification system for a hardware device under test (DUT) is a processor-based simulation acceleration/emulation system (hereafter “emulator”) in communication with one or more workstations that send stimuli to and from a DUT. Such stimuli can include digital test vectors or real signals from a logic system in which the DUT is intended for installation (sometimes referred to as a “target system”). For the specific case of a network DUT, a network tester application running on the workstation transmits test patterns (i.e., a collection of digital signals) to the emulator and also receives test patterns back from the network DUT residing on the emulator. The test patterns sent to the emulator for the network DUT of course depend on the nature of the network DUT. A network DUT that will operate as an IP router once manufactured will need to receive IP datagrams, as that is the protocol that it would encounter in real-world use. In the case of multiple tester applications sending and receiving test patterns and test patterns to and from the network DUT, multiple ingress and egress channels to the emulator are required. These channels may connect the emulator with a single workstation or multiple workstations at the choosing of the user of the system. In general, the delay caused by sending stimuli over the communication channels between a workstation and an emulator are substantial, resulting in relatively long functional verification times.
One way to increase the speed of the communication channel between a workstation and an emulator is through the use of a speedbridge. A speedbridge is a hardware devices that connects an emulated DUT to a workstation running a network tester application, where the workstation outputs stimuli in the format of a standard network communications protocol, for example transmission control protocol (TCP), IP, or Ethernet. A speedbridge is capable of buffering data received on its network side and reproducing the same data on its emulator side. A speedbridge can map the network communications protocol into a protocol recognized by the DUT of the emulator, for example the commonly-used media independent interface (MII), including 10 gigabit MII (XGMII). Use of a speedbridge presents several downsides, most notably that a speedbridge represents additional hardware, adding to the cost and complexity of the functional verification process. If a single speedbridge supports a single channel, a thirty-two-channel network DUT requires the use of thirty-two speedbridges. These additional hardware components are costly and take up additional physical space. The introduction of further hardware components also decreases the overall reliability of the system by introducing additional sources of potential failure. Furthermore, the ability to verify a network DUT using a particular network protocol is limited to the available speedbridges that support that protocol. For example, a speedbridge supporting Ethernet may be available, but any number of other networking protocols may have no speedbridge available.
An alternative method to increase the speed of functional verification in a system is to employ acceleration techniques, including a technique known as transaction-based acceleration (TBA). In general, TBA operates by partitioning test-bench functionality between a workstation and an emulator, and minimizing the volume of information transferred between the two across their connecting communication channel. When properly implemented, TBA may substantially decrease functional verification time by a substantial reduction of delay across the communication channel.
FIG. 9 depicts further detail of the components of an embodiment of a TBA interface between a testbench and the wrapper of a DUT in an emulator. A “wrapper” is software that acts as an adapter between two objects that are otherwise incapable of communication. Here, the DUT wrapper 901 is on the “hardware side” of the communications interface and the testbench is on the “software side.” The DUT wrapper 901 for the DUT 911, written in hardware description language (HDL), acts as an interface between the DUT 911 and the software of the testbench 902, which is written in another language, generally C/C++ or a hardware verification language (HVL). The wrapper includes interfaces for a clock 912, reset 913, and various communication channels 914 to 917.
Network tester applications used to test network devices are available from various suppliers, and it is desirable to use these tester applications during functional verification of a design under test in an emulator. These tester applications, in addition to supplying the network device with test patterns, monitor protocol compliance by the network DUT, characterize its performance in response to testing stimuli, provide a graphical user interface for the user of the functional verification system, and generate reports based on the results of the network tests. As such, tester applications are used for functional verification of an emulated network DUT. However, the use of acceleration techniques frequently requires that a tester application for a network DUT be modified, rewritten, or written entirely from scratch, increasing the time and cost of functional verification of a network DUT.